In many typical computing devices such as a personal computer, a game computer, a home video recording computer, and the like, the computing device includes a relatively large storage device upon which may be stored data relating the computing device, including of course applications that can be executed thereon and an operating system and/or file system (hereinafter ‘file system’) that is executed thereon to operate same and to allow access to the storage device. Inasmuch as the storage device is relatively large, the amount of space used by applications and the file system thereon is relatively insignificant, and accordingly issues of file maintenance, system upgrading, file access, file storage, and the like are not especially severe.
However, when the computing device does not include such relatively large storage device, but instead includes a relatively small storage device, the amount of space used by applications and the file system thereon can become relatively significant, and the aforementioned issues can and do become more severe. For example, when the computing device is a portable computing device or the like, such as for example a portable audio or video player or a portable game computer, and is of a relatively small size, it is likely that such computing device includes a relatively small storage device, especially inasmuch as the computing device is likely limited in the functionality required, in what applications can be executed thereon, and the physical size of storage device that can be accommodated. As should be appreciated, inasmuch as the storage device is relatively small, the amount of space used by the file system thereon is relatively significant, and accordingly issues of file maintenance, system upgrading, file access, file storage, and the like now require careful consideration.
One issue that must be considered is how an application or the file system on the relatively small storage device is to be updated. In particular, in a relatively large storage device, such updating may be achieved by successfully writing update data to an unused part of the storage device and thereafter deleting corresponding old data from another part of the storage device. However, in a relatively small storage device, space thereon may not be available to write the update data prior to deleting the old data, and accordingly the old data must be deleted in order to free space prior to writing the update data.
Critically, though, if the updating of the application or file system somehow fails and the old data thereof has already been deleted, there may be no way to restore the computing device to the previous state where the non-updated application or file system could be executed on the computing device. In the case of an application, such failure may be an annoyance until the application is reloaded, if possible. However, in the case of a file system, such failure may be catastrophic inasmuch as the computing device may be inoperable without a functioning file system. Accordingly, a need exists for a method for updating an application or file system on a computing device with a relatively small storage device, where the method ensures that the update will succeed or else does not allow the update to be performed.
Another issue that must be considered is how to store files on a relatively small storage device. In particular, in a relatively large storage device, storing files is performed on a per-cluster basis, with each file using at least one cluster which can be defined as 1, 2, 4, 8, or 16 kilobytes or more. Thus, if a file with only a small amount of data (one byte, for example) is assigned to a particular cluster, all the remaining space in such cluster will go unused by any other file and is thus wasted. Such wasted space is not especially significant in a relatively large storage device, especially one with a capacity on the order of tens or hundreds of gigabytes.
However, in a relatively small storage device, such wasted space can quickly grow to a significant level, and even to the point where the storage device runs out of space. For example, a storage device with a 16 megabyte capacity and a cluster defined as 16 kilobytes can only hold about 1000 files, even if each file is only a few bytes. Moreover, it can often be the case that the relatively small storage device such as that which was set forth above does indeed have stored thereon a significant number of very small files, on the order of a few to a few hundred bytes. Accordingly, a need exists for a file system framework that efficiently uses the storage capacity of a relatively small storage device without undue wasted space.
Still another issue that is to be considered is how to store a file on a relatively small storage device when the file contains portions of unallocated or null data. As may be appreciated, such unallocated or null data within a file is data for which space exists within the file, but where such data has not been established. For example, in a particular 128 kilobyte file, it may be the case that a middle portion thereof constitutes 32 kilobytes of null data which acts as a placeholder but is to be filled in at a later time with some type of information. Thus, such null data may be represented as all zeroes or the like, and again may be filled in at some later time with substantive information.
In particular, in a relatively large storage device, the entirety of such a file including such null data is stored, even though such null data represents nothing. As may be appreciated, such ‘stored’ null data is wasted space on the relatively large storage device that could instead be put to better use. However, and again, such wasted space is not especially significant in a relatively large storage device, especially one with a capacity on the order of tens or hundreds of gigabytes.
However, and again, in a relatively small storage device, such wasted space can quickly grow to a significant level, and even to the point where the storage device runs out of space. Moreover, it is to be appreciated that such wasted space can interfere when attempting to build a new file on such relatively small storage device based on an old file thereon, especially when the device is almost full. Accordingly, a need exists for a structure of a file that allows for efficient use of storage capacity of a relatively small storage device, especially when the file includes null data therein.
Yet another issue that is to be considered is how to execute a file on a relatively small storage device. In particular, in a computing device that would have such a relatively small storage device, such as for example a mobile telephone, a position locator, a music player, etc., a user likely wishes that a requested action be taken almost immediately. Put another way, if the requested action requires that an executable file be executed, such a user does not want to wait for however many seconds it could take for the file to be loaded from the storage device to a local RAM or the like and readied for execution. Moreover, in certain circumstances, the nature of the action may even demand almost immediate execution, such as for example if the computing device is a portable communications device that could be employed by emergency personnel during an emergency.
Accordingly, a need exists for a method and mechanism by which a file on the storage device of a computing device can be executed almost immediately. In particular, a need exists for a method and mechanism where the file is stored on the storage device and can be executed directly therefrom. Still further, a need exists for such a method and mechanism by which the file can be stored on the storage device in a fragmented manner and still can be executed directly from such storage device.